Google Cloud の RDBMS を徹底比較する登壇を行いました! #devio2024

Google Cloud の RDBMS を徹底比較する登壇を行いました! #devio2024

クラスメソッド Odyssey のリアルイベントで Google Cloud のリレーショナルデータベースを徹底比較して、どのように選ぶべきか発表してきました!

ウィスキー、シガー、パイプをこよなく愛する大栗です。

7月20日にクラスメソッドの設立20周年イベントである Odyssey のリアルイベント Day4 で Google Cloud の RDB の選択方法について登壇してきました。

Google Cloud の RDB を徹底比較! 選び方と最新機能紹介

データベース

データベースは、RDBMS 以外にも NoSQL や NewSQL などの分類がありますが、人気のデータベースランキングでも上位は全て RDBMS になっていて人気が根強いプロダクトになっています。しかし、データの扱い方として、生成 AI のブームによるベクトル検索やデータ量の増加なども重要になります。

Google Cloud では NoSQL を含め多様なデータベースのソリューションがあり、特にリレーショナルモデルのデータベースを複数提供しています。特に MySQL と PostgreSQL の DB エンジンでは複数の選択肢があるため、どのように選択すればよいのか検討が必要になります。

RDBMS ソリューション

MySQL と PostgreSQL を提供するデータベースサービスには、Cloud SQL Enterprise、Cloud SQL Enterprise Plus、AlloyDB(PostgreSQL のみ)があり、様々な違いがあります。インフラ的な構成の違いを確認すると Enterprise Plus は AlloyDB に近く、元々から存在した Enterprise(現行は第 2 世代)と比較して Cloud SQL の第 3 世代とも言えるような構成になっています。ここでは、パフォーマンスと機能性を深堀り、どのように決めるべきなのか考えていきます。

RDBMS ソリューション

パフォーマンスの比較

まずはパフォーマンスを比較します。Cloud SQL Enterprise Plus ではパフォーマンスに影響が大きいと思われるオプションとしてデータ キャッシュがあるため、比較対象は以下のパターンです。

  • MySQL
    • Cloud SQL Enterprise
    • Cloud SQL Enterprise Plus(データ キャッシュ無効)
    • Cloud SQL Enterprise Plus(データ キャッシュ有効 375 GB)
  • PostgreSQL
    • Cloud SQL Enterprise
    • Cloud SQL Enterprise Plus(データ キャッシュ無効)
    • Cloud SQL Enterprise Plus(データ キャッシュ有効 375 GB)
    • AlloyDB for PostgreSQL

計測対象のマシンスペックは小さすぎないスペックとして以下になります。Cloud SQL Enterprise は vCPU とメモリの割合が合わずメモリ量が少なくなっています。ディスクは Cloud SQL の Enterprise と Enterprise Plus は I/O がボトルネックにならないように大きくしています。

  • マシンタイプ:vCPU 8コア, メモリ 64GB(Enterprise は 52GB)
  • マルチゾーン(高可用性)
  • ディスク:1,667 GB※1(AlloyDB 以外)
    • ネットワーク スループット:2,000 MB/秒
    • ディスク スループット:Read 800 MB/秒、Write 800 MB/秒
    • IOPS:Read 15,000(MB/秒) Write 15,000(MB/秒)
  • 実行並列度:8, 16, 32, 64, 128, 256

実行するワークロードは TPC-C に類似のワークロードで、使用するデータサイズは約 200GB です。

  • 使用ツール:HammerDB 4.4
    • TPROC-C:TPC-C ライクで倉庫の在庫管理を模したもの
    • warehouse:2000
    • データサイズ:200GB 前後
    • 計測データ
  • 7 回計測
    • 最高/最低以外の数値(5回分)で平均を取得

以下に結果を提示しますが、 具体的な数値は未記載 であり、 読者が実施した場合に異なる傾向になる可能性がある のでご注意ください。

MySQL の結果

MySQL の結果を見ていきます。

MySQL の Enterprise では 128 並列で頭打ちとなり、通常の Enterprise Plus では 256 並列でもパフォーマンスが伸びています。データ キャッシュありの Enterprise Plus の場合は 32 並列の時点で通常の Enterprise Plus の 256 並列と同程度のパフォーマンスを発揮しています。データ キャッシュはローカルの SSD を使用するためクエリのレイテンシが改善されて低い並列度でもパフォーマンスが向上しているのではないかと思います。

MySQL の結果

月額の料金を確認するとパフォーマンスの順序と同様にコストも高くなる傾向があります。Enterprise Plus のデータ キャッシュはパフォーマンスの向上に対して料金の割合が少ないため、基本的にデータ キャッシュを有効化すべきだと思われます。

MySQL のコスト

PostgreSQL の結果

次に PostgreSQL の結果を見ていきます。

PostgreSQL の場合は Enterprise は並列度を上げてもパフォーマンスは大きく変化していません。また Enterprise Plus では 32 並列をピークに高並列度でパフォーマンスがなだらかに下がって行きますが、データ キャッシュの有無で明確なパフォーマンスの差が出ませんでした。AlloyDB は低並列度でのパフォーマンスはあまり高くないですが、高並列度までパフォーマンスが向上します。

PostgreSQL の結果

月額の料金を確認すると Cloud SQL Enterprise と Enterprise Plus ではパフォーマンスの順序と同様にコストも高くなる傾向があります。本計測ではデータ キャッシュで優位な差が見られませんでしたが、極端な費用差ではないのでワークロードに応じて有効にすべきだと思われます。AlloyDB では実際に利用したデータ量のみに応じてストレージコストが発生するため、本計測の環境では AlloyDB が Cloud SQL Enterprise Plus より低価格となっています。

PostgreSQL のコスト

更に CUD を 3 年で購入する場合には通常の Cloud SQL より AlloyDB の方が低価格になります。コミット利用で CPU やメモリは安くなりますがストレージの価格は変わらないため、このような逆転が発生する場合があります。

PostgreSQL のコストCUD3年

パフォーマンスに対する考察

パフォーマンスに対する考察として、

  • DB エンジンで差はありますが、Enterprise Plus はコスト効果が良く、今回の結果ではデータ キャッシュは MySQL の場合に高い効果を発揮しました。
  • AlloyDB は高並列度で高いパフォーマンスを発揮しました。
  • I/O インテンシブなワークロードでは、Cloud SQL ではディスクパフォーマンスを稼ぐためにストレージサイズを大きく確保する事があるため、AlloyDB の方が Cloud SQL より安くなる場合があります。

機能性の比較

次に機能性を比較します。Cloud SQL Enterprise は古いデータベースバージョンをサポートしており、CPU なども古いものが使用されています。Enterprise Plus と AlloyDB は以降の CPU を使用しており、コンピューティングは同等のスペックのマシンを使用しており、可用性 SLA も 99.99% になっています。メンテナンス時のダウンタイムは Enterprise Plus では高可用性の構成の場合に 1 秒未満で、AlloyDB ではシングルゾーンの構成でも 1 秒未満となっています。

Cloud SQL と AlloyDB の違い

Vector 検索について、PostgreSQL 互換の Cloud SQL と AlloyDB は pgvector となっており、AlloyDB では Google の高速なインデックスである ScaNN を使用しています。Cloud SQL for MySQL では ScaNN を使用した独自の実装を行っています。分析ワークロードの対応として、AlloyDB はカラム型エンジンにより高速な分析用オンメモリキャッシュを備えます。

その他のデータベースエンジン

それ以外の DB エンジンとしては Oracle データベースを使用するために、Bare Metal Solution for Oracle という Google Cloud と専用線で接続した近隣のデータセンターにあるベアメタルサーバー上に Oracle をインストールするソリューションが使用されます。これは Oracle を動作させて良い「承認されたクラウド環境」に Google Cloud が入っていないなかったため、Google Cloud の外側で Oracle をインストールさせて「承認されたクラウド環境」より CPU コアの計算を有利にしてライセンス費用を下げるという考えのもとの構成です。

しかし、2024年 6 月 11 日に Google Cloud と Oracle がパートナーシップを結び、2024 年後半には Google Cloud のデータセンターに専用のハードウェアを持ち込んでサービスを提供する Oracle Database@Google Cloud を提供すると発表されました。

Google Cloud が「承認されたクラウド環境」になったことにより、Compute Engine にインストールして使用することができるようになった反面、Oracle Processor Core Factor Table(コア係数)が適用されなくなりました。そのため Bare Metal Solution for Oracle のユーザーは今後 Oracle のライセンスに注意が必要かもしれません。

Oracle Database

RDBMS の選択フローチャート

Google Cloud には様々な RDBMS ソリューションがありますが、どのように選択すれば良いのか判断に迷うと思いますので、選択のためのフローチャートを作成しました。

RDBMS 選択フローチャート1

RDBMS 選択フローチャート2

RDBMS 選択フローチャート3

これで RDBMS の選択は完璧!

などと思わないでください。フローチャートでは主な判断材料と基に作成していますが、みなさん自信のビジネス要件など様々な制約条件があるはずなので、RDBMS 以外の選択肢にも目を向けて適切なソリューションを選択しましょう。

最後に一言ですが、それなりの規模でベンチマークを取得すると多量のリソースを必要とするので、コストに注意が必要です。(このベンチマークで大きな費用が発生して怒られました。。。)

さいごに

AlloyDB が 2022 年にリリースされ、Cloud SQL が Enteprise(今まで構成)と新しい構成である Enterprise Plus に分かれたのが 2023 年で、選択できるサービスが多くなりどうすれば良いのか迷ってしまう状況でしたので、全体を整理して発表しました。やはり AlloyDB は良くできていると改めて思ったので、MySQL 版の AlloyDB も作ってほしいなと感じました。

また、Cloud SQL Enterprise は古いバージョンの DB エンジンをどうしても使用しなければならない場合しか使い所がないと思いますので、読者の皆さんはバージョンアップを適切なタイミングで実施してください。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.